Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0056/612.txt

Text File | 1997-04-16 | 18KB | 423 lines

INFO-ATARI16 Digest         Mon,  6 Nov 89       Volume 89 : Issue 612

Today's Topics:
                              am I a DA
                            archive sites
         Congratulations (was: GEMDOS Extended Argument Spec)
                 GEMDOS Extended Argument Spec (LONG)
                         HARD DISK UTILITIES
                         Hard Drive Problems
                  Has anyone heard of TCOS database?
                         Laserjets and the ST
                 Memory upgrade affects performance?
                       PC emulator info request
   Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD
                              XLISP 2.0
----------------------------------------------------------------------

Date: 6 Nov 89 19:40:55 GMT
From: imagen!atari![e-mail]  (Ken Badertscher)
Subject: am I a DA

[e-mail] (H.Friedrich Kammer) writes:
| It is right that the startup code should
| do the right thing (mshrink or not), but there are startup codes
| available (e.g. APPACC.A) which ensure the correct startup in both
| cases.
 The problem is not whether the startup code should Mshrink or not.
The problem is finding the basepage address.  The method used by
all the startup code I have seen uses the text base address minus 256 as
the basepage address, and that is not the right way to find it.

| The other problem (find out the way the program is invoked)
| can be solved simply by using the AES-function shel_read, which
| returns a pointer to the string containing the program name
 Shel_read doesn't help if you are run from a command line shell which
doesn't launch programs using shel_write.  This is another example of
problems caused by ST programs having to live in two different worlds,
the worlds of GEM and GEMDOS.  Allowing the startup code to use A0 to
find the basepage address is our way of making it a little easier for
programs to live in both worlds.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

------------------------------

Date: 6 Nov 89 21:16:50 GMT
From: [e-mail] (Scott Yelich)
Subject: archive sites

In article <[e-mail]> [e-mail] (Sam Alan
 EZUST) writes:
>   does anyone know
>   1] why xanth's atari directory is empty?

because the people here who would set-up automatic archiving for
the network all own amigas.

I am working on some sort of archive site here....
most likely, it will be mail based and be batched out on the weekends...

no promises...

--

 -----------------------------------------------------------------------------
 Scott D. Yelich                                 [e-mail] [128.82.8.1]
 After he pushed me off the cliff, he asked me, as I fell, ``Why'd you jump?''
 -----------------------------------------------------------------------------

------------------------------

Date: 6 Nov 89 06:34:13 GMT
From: nis!pwcs!stag![e-mail]  (Dale Schumacher)
Subject: Congratulations (was: GEMDOS Extended Argument Spec)

[[e-mail] (John Buchanan) writes...]
> In article <[e-mail]> [e-mail] (Ken Badertscher) writes:
>>
>>GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION
>>
>>Introduction
>
>
> This is what we have being waiting for.  Nice to hear an OFFICIAL
> word about this whole mess.
>
>
> WELL DONE ATARI.

Humph.  It IS nice to have an OFFICIAL statement on a subject that should
have been settled YEARS ago, but what a statement it is!  I guess ATARI
figured that if they waiting long enough, and THEN posted a "standard",
we would forget all the good arguments AGAINST this particular form of
brain-damage.  This "new" extended argument spec is Mark Williams form,
with a thin (optional) layer of veneer on it, even after it was flatly
stated that the MWC form WOULD NOT BE ACCEPTED due to the ways in which
is was broken.  It appears that politics has won out over technical
merit once again.  I don't expect that Atari will change their mind on
this issue (without taking another YEAR to post an answer), but I will
include some information on how the MWC form (at that time) and Atari's
"new standard" are broken.  Remember, one of the design goals of this
standard is to be upward compatible with naive programs.

David Parsons wrote (in March):
| Say, for example, that I call the teeny-shell from a program that uses
| MWC arguments;  Teeny-shell will get ARGV=<0>ARG0<0><ARG1<0>...<0><0>.
| which will parse to at least one valid environment variable - ARGV=ARG0.
| If any of the arguments I passed into the teeny-shell have `=' in them,
| they, too, will get converted into valid environment variables. (if I
| do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.)
|
| And if this child (the one who doesn't grok the MWC `standard') does
| a putenv() or two, it will end up (most likely) putting new environment
| variables at the end of the arglist, after the corpse of the argument-list.
|
| The diddles to the length of the cmdline tail will prevent children from
| incorrectly reading the environment, but there will still be this
| collection of garbage left orphaned in the environment.  And if the teeny-
| shell calls another process that groks MWC args, which then forks off another
| process, well, then that orphan will see the first ARGV= value, which is
| now being treated as a valid environment variable, and get stuck with the
| fun prospect of trying to figure out if it is, indeed, the start of the
| argument list or if it's something else.
| Say, for example, that I call the teeny-shell from a program that uses
| MWC arguments;  Teeny-shell will get ARGV=<0>ARG0<0><ARG1<0>...<0><0>.
| which will parse to at least one valid environment variable - ARGV=ARG0.
| If any of the arguments I passed into the teeny-shell have `=' in them,
| they, too, will get converted into valid environment variables. (if I
| do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.)
|
| And if this child (the one who doesn't grok the MWC `standard') does
| a putenv() or two, it will end up (most likely) putting new environment
| variables at the end of the arglist, after the corpse of the argument-list.
|
| The diddles to the length of the cmdline tail will prevent children from
| incorrectly reading the environment, but there will still be this
| collection of garbage left orphaned in the environment.  And if the teeny-
| shell calls another process that groks MWC args, which then forks off another
| process, well, then that orphan will see the first ARGV= value, which is
| now being treated as a valid environment variable, and get stuck with the
| fun prospect of trying to figure out if it is, indeed, the start of the
| argument list or if it's something else.
| Say, for example, that I call the teeny-shell from a program that uses
| MWC arguments;  Teeny-shell will get ARGV=<0>ARG0<0><ARG1<0>...<0><0>.
| which will parse to at least one valid environment variable - ARGV=ARG0.
| If any of the arguments I passed into the teeny-shell have `=' in them,
| they, too, will get converted into valid environment variables. (if I
| do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.)
|
| And if this child (the one who doesn't grok the MWC `standard') does
| a putenv() or two, it will end up (most likely) putting new environment
| variables at the end of the arglist, after the corpse of the argument-list.
|
| The diddles to the length of the cmdline tail will prevent children from
| incorrectly reading the environment, but there will still be this
| collection of garbage left orphaned in the environment.  And if the teeny-
| shell calls another process that groks MWC args, which then forks off another
| process, well, then that orphan will see the first ARGV= value, which is
| now being treated as a valid environment variable, and get stuck with the
| fun prospect of trying to figure out if it is, indeed, the start of the
| argument list or if it's something else.

The major problem here is that the NUL separated pieces of the extended
argument list appear to the naive program AS ENVIRONMENT VARIABLES and
my be reshuffled (some shells may SORT them) by that program, modified
and passed on to a program which comforms to this "standard".  Now what
happens when this conforming program finds "ARGV=" right up at the front
of the (sorted) environment and THROWS AWAY THE WHOLE ENVIRONMENT.  It
does this because the command line length is not the magic value, thus
the "ARGV=" list is not from it's parent, but is still used to terminate
the environment!

\\   /  Dale Schumacher                         399 Beacon Ave.
 \\ /   (alias: Dalnefre')                      St. Paul, MN  55104-3527
  ><    ...umn-cs!midgard.mn.org!syntel!dal     United States of America
 / \\   "What is wanted is not the will to believe, but the will to find out,
/   \\  which is the exact opposite." -Bertrand Russell

------------------------------

Date: 6 Nov 89 19:53:06 GMT
From: imagen!atari![e-mail]  (Ken Badertscher)
Subject: GEMDOS Extended Argument Spec (LONG)

[e-mail] writes:
| Nice to get that document! I admit I have not read it yet, only
| searched for the word "official" - and failed. Comments?

Yes, it's official.
I guess I should have put a big header at the top reading:
"THIS IS THE OFFICIAL WORD FROM ATARI ON HOW TO DO THIS ARGUMENT STUFF"

I just wanted to release it to the public so it would get widely used.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

------------------------------

Date: 6 Nov 89 18:12:58 GMT
From: unisoft!bdt![e-mail]  (David Beckemeyer)
Subject: HARD DISK UTILITIES

What exactly was the "supply problem" your dealer is talking about?

We have all the HARD DISK SENTRYS you could want ready to ship.
Your dealer could call us directly if his/her distributor is
out of stock: [phone].
--
David Beckemeyer ([e-mail])       | "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools            |  no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610  |   - Headstone at Boot Hill
UUCP: ?uunet,ucbvax?!unisoft!bdt!david  |     Tombstone, AZ

------------------------------

Date: 6 Nov 89 19:40:44 GMT
From: shlump.nac.dec.com!engage.enet.dec.com!oldtmr![e-mail]  (Ray
 Wallace)
Subject: Hard Drive Problems

In article <[e-mail]>, @falcon.afit.af.mil (Gene Place)
 writes...
>I was in the process of moving files around and moved some .ACC files onto
>the root drive of my hard disk.  I reset my system to check how much memory
>those .ACCs had been taking up, but now every time my disk tries to
>boot, it causes a system reset.  I'm working on a 1040ST with a Haba 10
>hard disk.  Any ideas on how to get my drive to talk to me again?

Use DCformat to create a bootable floppy (a floppy with boot code on it),
DCformat has a button to click on to do this though I forget exactly what the
button says. Place this boot floppy in drive A, turn the computer OFF, wait
about five seconds, turn computer on. At this point the ST will BOOT the
floppy not the HD, all you have to do now is to run your hard disk boot
program (ICDBOOT.PRG et.al.), install a drive Icon for C:, open up drive C:
and delete the offending .ACCs.

Don't forget to keep the floppy around for next time (yes there will be a next
time :-)

---
Ray Wallace
                (INTERNET,UUCP) [e-mail]
                (UUCP)          ...!decwrl!oldtmr.enet!wallace
                (INTERNET)      [e-mail]
---

------------------------------

Date: 6 Nov 89 18:56:49 GMT
From: cs.utexas.edu!usc!sdsu!crash![e-mail]  (Diane Barlow
 Close)
Subject: Has anyone heard of TCOS database?

I have discovered a wonderful ``index card and button'' type database
called TCOS.  It's public domain, and supposed to be from Britain, but the
documentation that comes with it gives only a name of a person to contact
but *no address*!  I want to send in my $$ and my suggestions for
enhancements.  Perhaps someone else has heard of this program and knows
more about it?  Here's the info:

                TCOS version 1.2
                Perfect Evolution 1989
                Matthew P. Aubury

Can anyone supply me with more information?  Is there a newer version of
the program available anywhere?
--
Diane Barlow Close
      ?nosc, ucsd?!crash!canada
      [e-mail]
      Free Canada -- Trade Mulroney

------------------------------

Date: 6 Nov 89 18:25:16 GMT
From: fozzy![e-mail]  (Bill Hendricks)
Subject: Laserjets and the ST

I recently asked for info from people who had
the new HP Laserjet II-P, and got no responses.
OK, so it's a little soon to expect lotsa people
to have a II-P.

Let me rephrase the question:

Can anyone out there give me some idea of how
long it takes to print a full 8.5 X 11 page of
300 dpi graphics (like with _Calamus_ :-)) on
an HP Laserjet (of any kind)?

My local Atari dealer says that the "sale"
price on the SLM-804 of $1299 might have already
gone by, leaving the $1999 price again. (No way
I want to pay that kind of $$$ !!)

Thanks in advance for any/all info.

Regards,
Bill

------------------------------

Date: 6 Nov 89 20:04:21 GMT
From: imagen!atari![e-mail]  (Ken Badertscher)
Subject: Memory upgrade affects performance?

[e-mail] (daniel.m.kuster..jr) writes:
| The thing I don't understand is that the computer takes at least
| 4 times as long to boot (possibly longer).
 As numerous people have pointed out, the operating system clears
all of free memory for each program before loading.  Not only that,
but the original ROM TOS does this slowly.
 Also as some have pointed out, one solution is to use Pinhead, which
takes control of program loading when it sees GEMDOS clearing memory,
and only clears as much memory as the program needs.
 IMHO, a better solution would be for you to get the Rainbow TOS
upgrade. This allows you to speed up program startup selectively (some
programs insist on having all of memory cleared), AND it has lots of
other benefits as well.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

------------------------------

Date: Mon, 6 Nov 89 13:14 EDT
From: <[e-mail]>
Subject: PC emulator info request

    Well I'm ready to take the PC plunge,  No I don't mean I'm giving up
    on my ST.  I want to buy a PC emulator,  the only one I really know
    about is PC-Ditto II.  Could someone send me any information on this
    or other PC packages.

    Things like Cost
                Hardware
                Speed
                Compatibility
                etc...

    Any info at all would be greatly appreciated!!!!


                                         Thanks in advance    Bob

------------------------------

Date: 6 Nov 89 20:42:52 GMT
From: crdgw1!minerva![e-mail]  (B. S. Oplinger)
Subject: Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD

In article <[e-mail]>
 [e-mail] (Axel K. Olmos) writes:
>FDHD to ST conversion.                            By Axel K. Olmos

>     A MFS (Not HFS!) Partition on your hard disk with 720K free.
>                                OR
>     A  MFS formatted double sided disk.   (Note,  Spectre  double
>sided  disk  are usually formatted HFS,  you will need  a  special
>program to do this.)

You can use the formating program from your old Magic Sac or the
Double Click formatter/coppier program (forget the name).

>     2.   Run  Transverter.   Put  the MSDOS disk in drive  A  and
>set  the  ST source drive to A:.   Set the destination  Mac  drive
>to where ever your MFS disk or partition is.   When it asks you if
>you  want to strip linefeeds,  say NO.   When it asks for  creator
>name and type for both, say "SIT!".  (No quotes).  (I have heard reports
>that if your ST is one meg or less, you will have trouble transverting
>large files)

Transverter reads the entire disk into memory. On a 1Meg machine
there is only about 630K free after the transverter program is
loaded so that is the maximum file size. Note: you can fill up
the disk with files, the 630K rule is for any file, because
transverter only works one file at a time.

>P.S.  I  think if you format a disk on the Mac as MSDOS, then put it in
>an ST, and copy ST files to it, then put it back in the mac, you might
>be able to port ST files to the Mac...

Yes, but it isn't quite that simple. After you used Apple file
exchange and have the file on a MAC (BTW Stuffit files work
best), use ResEdit (1.2 or later) to open up the file. ResEdit
will give you a warning along the line of "the file does not have
a resource fork and opening the file will create one." Pick
yes/open/go ahead (whaterver the positive choice is). Now close
the file. All you wanted to do is make a resource fork for the
file. Now use a file maintenace utility and set the file type
and owner to "SIT!", again no quotes or use ResEdit (sorry I
don't use resedit for this and cannot give directions).

brian
[e-mail]

--
<#include standard.disclaimer>

------------------------------

Date: 6 Nov 89 14:58:16 GMT
From: Teknowledge.COM!unix!excelan!leadsv!laic![e-mail]
 (Gary Trimble)
Subject: XLISP 2.0

I have been unsucessfully trying to get the sources for Dave Betz's
XLISP 2.0. If you have these or know where I can find them, please
respond via email. Thanks!

------------------------------

End of INFO-ATARI16 Digest V89 Issue #612
*****************************************
=========================================================================